REMARKS 

Applicant respectfully submits that no new matter is added. 



Charge Deposit Account 



Please charge any shortages and credit any overages to Deposit Account 
No. 02-2666, including any shortages caused due to insufficient funds for an 
accompanying check. Any necessary extension of time for response not already 
requested is hereby requested. Please charge any corresponding fee to Deposit 
Account No. 02-2666. 




Respectfully submitted, 
BLAKELY, SQii0i:^3F5i-TAYllOR & ZAFMAN 



Date: 



Daniel M^De Vbs 
Reg. No. 37,813 



12400 Wilshire Boulevard 
Seventh Floor 

Los Angeles, CA 90025-1026 
(408) 720-8300 



VERSION WITH MARKINGS TO SHOW CHANGES MADE 



IN THE TITLE 

A title was added. 

IN THE SPECIFICATION 

The paragraph beginning on page 27, line 17 has been deleted. 

Please replace the paragraph at page 12, line 1, with the following rewritten 

paragraph: 

In addition, Figure IB shows metadata objects 120A-i associated with 
underlying functions. Particularly, metadata objects 120A and B respectfully 
identify action units 105A and B. Additionally, Figure 4- IB shows metadata 
object 120C directly stores one of the functions (also referred to as an internal 
function), and therefore does not need an action unit. Among other things, a 
metadata object can store information describing the input and output 
"parameter kinds" to it's underlying function. It is worthwhile to note that the term 
parameter kind is not used herein as synonymous with data type. Rather, the 
phrase parameter kind refers to a type of information (e.g.. name, street address. 
Id). Thus, two different parameter kinds (e.g., name and street address) may 
share the same data type (e.g., string). 

Please replace the paragraph beginning at page 12, line 10, with the following 
re-written paragraph: 

A metadata object typically does not contain the values to be used as 
input parameters to the underlying function. Rather, an execution object is 
formed to maintain a context (e.g., input parameter values and resulting output 



parameter values) for an underlying function. As such, one or more execution 
objects may be associated with each METADATA object. Figure 1B shows 
EXECUTION objects 1 25A-X - 1 25i-x. Particularly, Figure 1B shows 
EXECUTION objects 125A-A through 125A-I identifying METADATA object 
120A, EXECUTION object 42§B-A 125B identifying METADATA object 120B, 
EXECUTION obiect 125C identifvino METADATA obiect 120C. and 
EXECUTION object 42§i-A125i identifying METADATA object 120i. 

Please replace the paragraph beginning at page 14, line 1, with the following re- 
written paragraph: 

With regard to the set of keys used to distinguish the parameter kinds, 
each function being tracked by the integration layer can have one or more input 
parameters and one or more output parameters. A naming convention is used 
for the different parameter kinds used by the functions. Different functions may 
share one or more of the same parameter kinds. To illustrate, consider the 
previous example where function A has as parameters an Id and a street 
address, while function B has as parameters a name and a street address. In 
this example, functions A and B share the Id street address parameter (they 
share the same parameter kind). In addition, this example has three parameter 
kinds (Id, street address, and name). 

Please replace the paragraph beginning at page 23, line 17, with the following 
re-written paragraph: 

The EXECUTION class 900 of Figure 9 includes the following structures: 
NAME: qP¥RE CLASS LABEL : PARAMS; METADATA_OBJECT_PTR; and 



MANAGER_PTR. As previously described, each execution object is associated 
with a metadata object. In one embodiment, the NAIVIE structure of an execution 
object contains the same data as the name structure of the METADATA object to 
which it is associated. In alternative embodiments, the NAME structure need not 
store the same data, but rather a name to name look-up structure is used. The 
CLASS_LABEL structure of the EXECUTION class 900 is used for the same 
purpose as the CLASS_LABEL structure of the METADATA class. 

Please replace the paragraph beginning at page 26, line 18, with the following 
re-written paragraph: 

Figures 1 1 A-B are block diagrams illustrating two additional classes of the 
integration layer of Figure 1 A according to one embodiment of the invention. 
Figure 1 1 A is a block diagram illustrating a context class 1 100 according to one 
embodiment of the invention. The context class includes the following 
structures: NAME; KEY_VALUE_COLLECTION; and 
EXECUTION_COLLECTION ; and EXECUT I ON_PATH_COLLECT I ON . 

Please replace the paragraph beginning at page 27, line 22, with the following 
re-written paragraph: 

Figure 1 1B is a block diagram illustrating a MANAGER class according to 
one embodiment of the invention. A manager object can be used for managing 
the execution objects. The MANAGER class 1110 includes the following 
structures: CONTEXT_COLLECTION; DEFAULT_CONTEXT; and 
EXECUTION COLLECTION : and EXECUTION PATH COLLECTION . 
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A paragraph was added beginning at page 28, line 1 8. 

Please replace the paragraph beginning at page 52, line 10, with the following 

re-written paragraph: 

Figure 20 is a block diagram illustrating the PARAMETER_SATISFY 
method according to one embodiment of the invention. The 
PARAMETER_SATISFY method receives the same inputs as the 
FIND_BY_NEED method previously described (see block 2000 1700) . From 
block 2000, control passes to block 2005. 

Please replace the paragraph beginning at page 53, line 17, with the following 
rewritten paragraph: 

Specifically, the common concept of encapsulation in object technology is 
to place data with its' associated methods together in a single object. In 
contrast, the integration layer is developed such that those methods that express 
a relationship (referred to herein as "relationship methods") are placed in 
separate objects— the relationship objects. In this manner, a higher degree of 
encapsulation is provided. While relationship methods within relationship objects 
are similar to methods commonly found in object technology in that they can be 
applied to the objects that contain them, relationship methods within relationship 
objects are different in that they often are applied to other objects, including base 
objects and other relationship objects. For a further description of relationship 
objects, see "A Method and Apparatus for Providing Relationship Objects and 
Various Features to Relationship and Other Objects," filed - 
September 30. 1998 . by Bhalchandra Ghatate, which is herein incorporated by 
reference. 



-11- 




IN THE CLAIMS: 

Claims 2-46 have been cancelled without prejudice. 



Ms 
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